Lambda the Ultimate

• http://www.cse.unsw.edu.au/~cs3141/
• http://www.cse.unsw.edu.au/~cs3141/mindmap.html (Java required)
• http://www.cse.unsw.edu.au/~cs3141/index.php?module=articles&func=display&ptid=1&aid=62

Lecture links can be found in the forum description for each week. Lab and assignment links can be found under "News".

In the last offering, I gave prizes to encourage discussion. In the next offering, I am thinking of giving prizes for the top players of the Speculative Search Game, where the topics must be relevant to the course. (See: http://www.cse.unsw.edu.au/~amichail/spec.)

I plan to make the course open again, meaning that anyone can participate in discussions, games, etc.

Any feedback would be appreciated.

BitC language specification, version 0.4. Out of the new Coyotos project, successor of Eros and KeyOS, comes this new language:

BitC is conceptually derived in various measure from Standard ML, Scheme, and C. Like Standard ML [CITE], BitC has a formal semantics, static typing, a type inference mechanism, and type variables. Like Scheme [CITE], BitC uses a surface syntax that is readily represented as BitC data. Like C [CITE], BitC provides full control over data structure representation, which is necessary for high-performance systems programming. The BitC language is a direct expression of the typed lambda calculus with side effects, extended to be able to reflect the semantics of explicit representation.

(via Slashdot)

I guess this may be more of a compiler issue than a language design issue, but with the recent excitement over Cell processors maybe people will have some insights.

Basically, I'm interested in processor/hardware support for higher level language concepts. In particular I've been looking for what exactly made Lisp Machines so much better for Lisp than normal hardware(so far not really found much), but its not just Lisp machines I'm interested in. I've been hearing about type-safe assembly languages, and I wonder what it would take to have hardware support to help with things like multithreading(besides the obvious "just use multiple processors" :) ), and garbage collection. I guess Transmeta's processors had some interesting possibilities too, but I've not heard of them being exploited.

I know that some VM's(like Parrot and .Net) help out with these things, and I've heard that the JVM has been implemented in hardware, but has anyone had much experience with hardware support stuff like this? Are these VM's really appropriate for hardware support or is there yet-another-way which would be better? Partially I just don't know what keywords to look for.

Here is part of a discussion from the "Language Smiths" discussion group that I thought might be of interest to some here:


From: http://groups.yahoo.com/group/langsmiths/message/2281




--- In langsmiths@yahoogroups.com, Daniel Ehrenberg

> What are your goals with this language? Are you trying

> to be popular, or are you trying to make a good

> language?

My goals are probably the same as just about every other language
designer: to create a better language for me to create the types of
programs that I typically need to create. What is perhaps slightly
different for me is the types of programs that I typically need to
create. I write large enterprise class applications for: financial
institutions, the telecom industry, huge inventory systems, CRM and
e-commerce. This is probably the sort of thing that about 90% of the
world's programmers work on I'm guessing. (In short: the types of
programs that nobody would every write for fun.) The types of
programs that I write a far too large for me to write on my own so I
need to make my language acceptable to the masses if I want to be able
to use it. As a result, I want to make a language which is useable by
90% of the worlds' programmers (and some percentage of the world's
non-programmers). Language experts design languages for their own
needs, and because they're always writing languages, we end up with
many languages which are excellent for language experts to write
languages in. Languages for their own needs and for their own kind.
Unfortunately, the offerings for non-language designers to create
non-languages in, is drastically under-served.

Computer languages are actually for people, not computers. The
computer is happy with machine code. If you make something which is
for people but then most of the people don't like it, then you've
failed. Could you imagine a Chef saying "do you want me to make good
food, or food that people like?" It sounds like a ridiculous thing
to say in the context of food (or clothing, or anything else
supposedly designed for people) and yet it seems to be the common
belief in the design of programming languages.

I wouldn't say that being "good" and being "popular" are mutually
exclusive. A popular language is more likely to have better compilers
and tools, be available for any particular platform, and more likely
to have some desired functionality already implemented by someone
else. Pragmatically, a language which lets me *not* write something
because it has already been written by someone else, is better than a
language which lets me write it any number of times faster. I'm more
likely to be able to buy a book about a popular language, or to write
a book about a popular language and get paid for it. I'm more likely
to be able to find a job or conversely to hire developers for a
popular language. Popularity is a feature, and in many cases, the
most important one.

...at Language Design Docs.

Forwarded message from Timothy J Hickey
-----

Cc: peter@norvig.com, Geoffrey Knauth ,
Kathleen Huber
From: Timothy J Hickey
To: JScheme Developers ,
Jscheme Users
Subject: [Jscheme-user] Sad News about Ken Anderson
Date: Sat, 22 Jan 2005 09:37:37 -0500

Dear JScheme community,

I'm sorry to bring you the very sad news that Ken Anderson,
one of the co-developers of JScheme, died last night at the Spam
conference
in Cambridge. He was in great spirits, talking about JScheme, when
he collapsed mid-sentence.

Ken was one of the three main developers of JScheme.
JScheme had two parent languages -- Peter Norvig's SILK
and Tim Hickey's Jscheme applet. Ken came onto the project
in the beginning (1997) and built the Scheme-Java interface that became
the javadot notation. He was responsible for the beautifully designed
cache techniques that make javadot so efficient. He also
was a tireless developer, chasing down bugs, dreaming up and
seriously analyzing proposed new optimizations. He was a
talented software engineer who loved building an elegant
and simultaneously practical language. He was also a really
nice guy. Kind, generous, thoughtful. The world is a poorer
place for his passing.

Ken touched many lives and brought many communities together.
I worked with him on JScheme for 2-3 years (publishing two papers)
before I met him in person (or even knew what he looked like!)
We've met regularly since to plot the future of JScheme and to
share our war stories of JScheme in the world. He has played
a major role in the Lightweight Language conferences and was
also an active player in the anti-Spam effort. I will miss him,
as I'm sure many other will as well.

JScheme will remain an active project and is very much part
of what Ken has given to the world. I am honored to have been
his friend and codeveloper.

Sincerely,

---Tim Hickey---

Just skimming through the Design Docs page and noticed there are links to Python PEPs. Tcl's equivalent are TIPs and are available at http://tip.tcl.tk/ in case you want to add the link. Hope this is the correct way to submit a new link.

(Also, as someone noted a while ago "Quick Qoutes" (sic) is still misspelt in the menu.)

I was looking at at some memory profiles of a misbehaving Haskell program a while back, and the electrical engineer in me couldn't help but think that the graphs looked very much like step responses. And it got me to thinking about how lazy programs with a space leak might be thought of as being an unstable dynamic system (a pole in the RHP). You deal with problems like that with Control Theory. But how do you apply it to a Haskell program? Maybe with something like Eager Haskell. My understanding of Eager Haskell is that it tries to execute your program eagerly, and when it starts to exhaust memory (from trying to evaluate an infinite list, etc.) it resorts back to laziness. That doesn't seem very sophisticated. But what if the "eagerness" knob was available to the program itself, or maybe another agent. You could then start to think about building better controllers. What variables would we want to control? I don't know, and it would probably depend on your algorithm, but interesting candidates might be: rate of change of memory usage, speed at which characters are written to your output file, ratio of memory usage to CPU usage (i.e. we're creating a lot of thunks that aren't being evaluated), etc. I could also imagine that applying a dose of control theory to the behavior of lazy programs might make it easier to reason about their resource usage. Heck, even if it didn't lead to anything useful, it might be interesting to put PID controller into your runtime system, just to see what happens.

The long awaited sequel to Types and Programming Languages by Benjamin Pierce is out! Check it out here:
Advanced Topics in Types and Programming Languages.

It is available from amazon. I'm certainly getting a copy. TAPL was great!

A recent poll found that Jython was the favorite JVM-based scripting language among those polled, weighing in at 59%. Groovy came in second at 15%.